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I. REAL PARTY IN INTEREST 

The real party in interest is Visa International Service Association, a subsidiary of 
Visa Inc. 

II. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or judicial proceedings known to the Appellants. 

III. STATUS OF CLAIMS 

Allowed claims: None 

Claims objected to: None 

Claims rejected: 1-6 and 1 1-16. 

IV. STATUS OF AMENDMENTS 

A response was filed by Applicant on September 8, 2009 in response to a Final 
Office action dated July 8, 2009; no amendments were presented. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

A personalization assistant software tool is used by smart card issuers (such as 
banks) to tailor a batch of smart cards to best suit their market needs. Often card issuers 
become mired in the technical details of personalizing smart cards before delivering them 
to their customers and, consequently, lose sight of the business and risk management 
decisions that should dictate smart card features. Card issuers use the personalization 
tool for selecting and choosing appropriate values for these business and risk 
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management decisions. The personalization assistant guides issuers through the decision- 
making process of selecting their desired options and prompts. Issuers respond to a series 
of business questions. Responses to these questions are used by the personalization tool 
to generate a set of smart card parameters and values, representing the issuer's business 
and risk requirements for smart card debit and credit applications. The personalization 
assistant assists the card issuer with default values and queries. The actual mechanics of 
identifying the data values to be used in the data personalization process is transparent to 
the issuer, who is then free to focus on the business and risk management aspects. The 
software tool then generates a personalization data file suitable for personalizing the 
issuer's batch of smart cards. 

Claim 1 recites a method of automating the personalization of a batch of smart 
cards originating with a smart card issuer. The process begins with executing a 
personalization assistant software tool (page 10, lines 19-22; Fig. 5, step 416; Fig. 3, 320; 
Figs. 31 and 32), the software tool including a default member profile (Fig. 8) having 
default values for smart card features (Fig. 15, 1504), a smart card feature being a 
parameter representing a business requirement of the smart card issuer dictating smart 
card usage. (Page 5, lines 15-20; Fig. 16, 1604; Fig. 17, 1704; page 14, page 31). A user 
is provided with queries regarding the smart card features, the queries originating from 
the personalization software tool. (Page 11, lines 7-10; Fig. 4, 408). Responses to the 
queries are received by the software tool from the user, where the responses reflect smart 
card features desired by the card issuer. (Page 11, lines 10-12; Fig. 4, 412). The 
responses are matched with output data values, wherein the matching is performed by the 
software tool, and where each of the output data values represent one of the smart card 
features and is suitable for personalizing a smart card. (Page 11, line 29 - page 12, line 
6; Fig. 5, 504). The default member profile is modified to include the matched output 
data values, where the output data values replace corresponding default values for the 
smart card features. (Page 15, lines 26-28; page 16, lines 6-10; Fig. 10, 1012; Fig. 12, 
1204). A personalization data file is generated from the modified default member profile, 
the personalization data file being suitable for personalizing the smart cards and 
providing the smart card features on each smart card by way of the output data values. 
(Page 11, lines 12-14; page 12, lines 7-8; Fig. 4, 416). 
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Claim 1 1 recites a computer-implemented method of automating the 
personalization of a batch of smart cards originating with a smart card issuer. The 
process begins with executing, on a host computer (page 10, lines 18-24; Fig. 3, 316), a 
personalization assistant software tool (page 10, lines 19-22; Fig. 5, step 416; Fig. 3, 320; 
Figs. 31 and 32), the software tool including a default member profile (Fig. 8) having 
default values for smart card features (Fig. 15, 1504), a smart card feature being a 
parameter representing a business requirement of the smart card issuer dictating smart 
card usage. (Page 5, lines 15-20; Fig. 16, 1604; Fig. 17, 1704; page 14, page 31). A user 
is provided, over a network (page 10, lines 17-19; Fig. 3, 312), with queries regarding the 
smart card features, the queries originating from the personalization software tool. (Page 
11, lines 7-10; Fig. 4, 408). Responses to the queries are received by the software tool 
from the user over the network (page 10, lines 17-19; Fig. 3, 312), where the responses 
reflect smart card features desired by the card issuer. (Page 11, lines 10-12; Fig. 4, 412). 
Combinations of responses are matched with output data values by the personalization 
assistant software tool. (Page 27, line 24 - page 28, line 3; Fig. 49; Fig. 31, 3104). The 
default member profile is modified to include the matched output data values, where the 
output data values replace corresponding default values for the smart card features. (Page 
15, lines 26-28; page 16, lines 6-10; Fig. 10, 1012; Fig. 12, 1204). A personalization data 
file is generated from the modified default member profile, the personalization data file 
being suitable for personalizing the smart cards and providing the smart card features on 
each smart card by way of the output data values. (Page 11, lines 12-14; page 12, lines 7- 
8; Fig. 4, 416). The smart cards are personalized utilizing the personalization data file 
which contains smart card features on each smart card by way of the output data values. 
(Page 11, lines 13 - 23; Fig. 4, 420). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The rejections presented for review are as follows: 

Claims 1-3, 6, 11-13 and 16 are rejected under 35 U.S.C. §103 as being 
unpatentable over Tushie et al. (U.S. Pat. No. 6,014,748) in view of Da (U.S Pub. No. 
2001/0042212). Claims 4, 5, 14, and 15 are rejected under 35 U.S.C. §103 as being 
unpatentable over Tushie et al. in view of Du, and further in view of Anderson et al. (U.S. 
Pat. No. 5,884,289). 

VII. ARGUMENT 

With respect to the grounds above, the rejected claims are argued as a single 

group. 

A. The Present Invention 

i) General Overview 

The present invention addresses ways for a smart card issuer to automatically 
personalize a batch of smart cards before delivering the cards to customers. Figure 3 
shows a personalization tool 320 on a host computer that generates a data file 138 that is 
used eventually in a personalization device 150 to personalize smart cards. 

The process begins with running a personalization software tool on a host 
computer in order to ask a smart card issuer questions about the issuer's business and risk 
management requirements with respect to smart card usage. The answers to these 
questions are used to obtain specific values. A personalization data file is generated 
based on these specific data values. The personalization data file — generated by asking 
questions of the card issuer and evaluating the responses — may then be used by the card 
issuer to personalize the actual smart cards. The invention uses what is referred to as a 
"smart card feature" to carry out this process. 
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A smart card feature is a parameter representing a business or risk management 
requirement or preference of the smart card issuer and is derived from asking questions of 
the card issuer. A personalization assistant software tool (item 320 in Figure 3) presents 
such queries to the issuer. An example of this is shown in Figure 31. In this screen shot, 
the card issuer is presented with seven queries relating to cardholder verification methods 
(CVM) — an area that may fall under risk management requirements of the card issuer. A 
responds to these queries by clicking on a "Yes" or "No" button. Figure 32 shows 
sample smart card features based on the responses to the queries presented in Figure 31. 
For example, for the fifth query: "Manual cash and purchase transactions with 
cashback?," a smart card feature is "Signature is required when the device does not 
support Online PIN." For the sixth query: "Purchase transactions without cashback?," a 
smart card feature is "Offline Enciphered PIN is used if the device supports it." Other 
examples of queries presented to the issuer by the personalization assistant software may 
be found in Figure 36 ("Making Your Offline Data Authentication Risk Management 
Decisions") and in Figure 38 ("Defining Your Issuer Authentication Options"). As 
described below, the processes of the invention allow card issuers to focus on the 
business and risk requirements instead of on the technical and engineering aspects needed 
to encode these requirements onto smart cards. By personalizing the smart card with 
smart card features and output data values, the card can operate without instructions from 
the card issuer. Thus, when the smart card is being used and a smart card feature is 
invoked, the card does not have to receive any instructions from the card issuer with 
respect to the feature because the answer is already encoded upon the card in an output 
data value. 

ii) Interpretation of "Smart card feature" 

Claims 1 and 1 1 recite in the first step that " a smart card feature is a parameter 
representing an issuer business requirement dictating smart card usage ." As noted above, 
a "smart card feature" is a business or risk management requirement of the smart card 
issuer, such as whether or not to require a signature or a PIN when a smart card is used. 
Support for this limitation may be found at pages 5 and 6 of the specification: 
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The personalization assistant guides issuers through the decision-making 
process of selecting their desired debit/credit options. Issuers are 
requested to respond to a series of business questions. Responses to these 
questions will be used by the tool to generate a set of debit/credit 
parameters and values, representing the issuer's business and risk 
requirements for the debit/credit application. . . . The actual mechanics of 
capturing the data to be used. . .will be transparent to the Issuer who is then 
free to focus on the business/risk management aspects of this process. 

Other sections of the specification also support this description of "smart card features." 
For example, Figures 16 and 17 describe various business requirements and the screen 
shot in Figure 16 provides: "In addition, you can support optional features based on your 
market requirements." Page 14 (describing Figure 8) states: "... responses to a plurality 
of queries form business decisions 804, which are provided as input to the personalization 
assistant 320." In another example, page 31 of the specification states that "the invention 
provides a user friendly tool that is able to take business related answers to generate 
technical settings . . . without requiring the understanding of the technical settings." 

A claim term must be interpreted by first looking at the intrinsic evidence, which 
begins by looking at the claims themselves and the specification. As the claim language 
and the citations to the specification above show, Applicant has provided explicit claim 
language and numerous examples and explanations throughout the specification to clarify 
what it means by "smart card features." Therefore, following established tenets of claim 
construction, this term must be interpreted as a parameter representing an issuer's 
business requirements that dictate usage of the smart card by customers, and not 
something different such as a customer account number. 

B. The Tushie Reference 

With this description of smart card features and output data values in mind, we 
now turn to the cited references. The primary reference in the §103 rejection is Tushie. 

i) Tushie Does Not Disclose "smart card features" 

Tushie uses the term "personalization" but in an entirely different context from 
that of the claimed invention. The personalization data in Tushie does not relate at all to 



10/633,020 



6 



VISAP076/P-13601 



smart card features as decided by a smart card issuer, but rather is directed to basic 
cardholder data , such as name, account number, expiration date, and so on. This type of 
basic cardholder data is not a smart card feature as claimed. Basic cardholder data is not 
" a parameter representing an issuer business requirement dictating smart card usage " as 
required in claims 1 and 1 1 . 

ii) Tushie Does Not Disclose Querying a User and Receiving Responses 

The second and third steps of claims 1 and 1 1 require that the user be queried 
regarding the smart card features, and that the user provide responses reflecting smart 
card features desired by the card issuer. The Office action (page 4, lines 5-8) cites Tushie 
as disclosing the step of receiving responses to queries reflecting smart card features. But, 
cardholder data 152 in Figure IB of Tushie is standard personalization data that is unique 
to each cardholder. As explained above, this data is entirely different from the smart card 
feature data and their output data values of claims 1 and 1 1 . Also, as previously 
explained, this personalization data comes from the card issuer unchanged. There is no 
opportunity for any individual in Tushie to respond to queries and provide responses 
indicating values for particular smart card features. In the present invention, the second 
and third steps require that the user using the personalization assistant software tool not 
only is presented with queries but also provides responses, specifically, smart card feature 
information. 

Moreover, even if the personalization data in Tushie was in some manner 
analogous to the claimed "smart card features" (which Applicant denies), the creation of 
smart card features and data values by querying a smart card issuer is not disclosed in 
Tushie. Claim 1 specifically requires: 

providing a user with a plurality of queries regarding said smart card 
features, said queries originating from said software tool; and 

receiving from the user, responses to the plurality of queries, said 
responses being received by said software tool and reflecting smart card 
features desired by said smart card issuer. 

Thus, claims 1 and 1 1 require determining the smart card features desired by the 
smart card issuer by querying a user of the personalization assistant software tool. There 
is no such querying disclosed in Tushie. As shown in Figures 1A and IB of Tushie, basic 
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cardholder data is sent from a database 152 straight to system 150 and then on to 
personalization system 100. This data is not modified or generated by queries; it comes 
unchanged straight from a database. In other words, the personalization data in Tushie is 
simply transmitted from the card issuer and is not changed or modified in any way. (See 
Tushie, "Data" from 150 to 100 in Figure 1A and cardholder data moved from 152 to 150 
to 100 in Figure IB.) 

In Tushie, there are no queries presented to any party or responses evaluated in 
order to create the personalization data. Tushie focuses on taking raw cardholder 
personalization data (which is actually basic cardholder data, as opposed to business and 
risk management data of the card issuer) and simply delivering it unchanged to system 
100. 

iii) Tushie' s "data format template" and "card framework template record" Do 
Not Disclose "smart card features" 

The final Office action cites the "card framework template record" in Tushie 
(columns 2 and 18), as disclosing the claimed smart card features. At the top of page 4 of 
the final Office action, it is pointed out that entries such as the account name and account 
number correspond to the claimed "default values for smart card features." But, an 
account name and an account number are simply static data specific to a particular 
cardholder. These values do not reflect a business requirement of the smart card issuer 
dictating how the smart card must be used, such as whether or not a signature is required. 

The Office action also cites the "card framework template record" as disclosing 
smart card features and their values. But, this template merely "describes the structure of 
the chip on the card" (Tushie column 18, lines 5-6). For example, Figure 11 in Tushie 
shows the card framework template. It includes technical information such as system 
definitions, templates for embossing or for the magnetic stripe, application data, etc. (See 
Tushie, column 17, lines 26-31). This cardholder data does not disclose or suggest high- 
level issuer business requirement data. 

In addition, the modifying and generating steps of the claims require that the 
output data value for a smart card feature is used to personalize a batch of smart cards. In 
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other words, the smart card feature is applied to the entire batch of smart cards; each 
smart card has the same value for a particular feature. By contrast, in Tushie, data such 
as account name and account number must be different for each and every smart card. 
Therefore, data entries, such as account name or number cannot correspond to default 
values for smart card features as claimed. 

Page 3 of the final action cites the "data format template" disclosed in Tushie. As 
explained in Tushie the point of the issuer "data format template" is to allow the 
personalization system in Tushie to interface with multiple card issuer systems while 
ensuring that the personalization data is formatted correctly for each system. (Column 2, 
lines 54-59). By contrast, the invention of claims 1 and 11 is not interfacing with 
different issuer systems; smart card features of the claimed invention are elicited from the 
card issuer and applied to a batch of smart cards. The "data format template" in Tushie 
does not disclose smart card features and their values because the "data format template" 
simply tells the personalization system in Tushie how to use individual cardholder data. 

C. Du Does not Disclose Smart Card Features 

The Office action on page 4 cites Du as disclosing the second step of claim 1 : 
"providing a user with a plurality of queries regarding smart card features." But, Du 
cannot possibly disclose queries regarding smart card features because Du discloses 
queries related to configuring the user's personal computing environment (paragraph 48). 
A smart card issuer's business requirement regarding how a batch of smart cards must be 
used is entirely different from a question to a computer user regarding his or her favorite 
Web site. As noted, "smart card features" must be interpreted as a parameter 
representing an issuer's business requirements that dictate usage of the smart card by 
customers. Although Tushie shows cardholder data and Du discloses personal 
configuration queries to a user, neither shows smart card features as claimed. 

D. Not Obvious to Combine Because Du is Non-analogous Art 

It would not have been obvious to combine Du with Tushie because the art is 
entirely different. Tushie deals with trying to make personalization data suitable for any 
type of smart card personalization equipment, while Du deals with creating a portable 
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computing environment. One of skill in the art trying to personalizing a smart card 
would not be concerned with how to make it easier to make a computing environment 
portable. 

More specifically, Tushie deals with the personalization of batches of smart cards 
by a bank using personalization equipment before the smart cards are delivered to users 
(Figure 1A). It describes a manufacturing process that involves feeding, for example, 
thousands of blank smart cards into sophisticated personalization equipment where they 
are stamped, embossed, programmed, etc. Tushie deals primarily with how to 
personalize these smart card batches using a variety of types of personalization 
equipment. 

By contrast, Du deals with how a computer user might replicate their office 
computing environment on a computer in a remote office. The user possesses a smart 
card, but the card has long since been manufactured, personalized and issued by the bank 
to the user. The user is able to transfer a representation of their computing environment 
onto the smart card and then insert the smart card into a remote computer to help transfer 
that computing environment. The result is that the user is able to use their familiar 
browser, bookmarks, word processing templates, etc. A smart card is not required; one 
might transfer the data using a hard disk or other portable memory device. 

The only element that Du and Tushie have in common is that the two references 
use the term "smart card." An analogy might be if one reference dealt primarily with 
programming the firmware of thousands of laptop computers in a factory, and a second 
reference dealt with how a single user might use a single laptop to read e-mail. The two 
references would not be analogous. 

For these reasons, one of skill in the art of personalizing smart cards (such as 
Tushie) would not be motivated to inquire into the field of "how can I move my 
bookmarks from one computer to another?" (such as Du discloses), and would be 
unaware of the art in that field. Therefore, one of skill would not be motivated to 
combine the two references. 
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Finally, Du is not in the field of Applicant's endeavor as suggested in the 
Advisory Action (continuation of Item 11, note 3). Du is in the field of moving a user's 
personal computing environment from one computer to another, while the present 
invention, as well as the invention in Tushie, deals with the manufacturing of smart cards. 
A person of ordinary skill in the field of manufacturing batches of smart cards would not 
have any apparent reason to look in Du's field of mobile personal computing to improve 
on a system in Tushie' s field of manufacturing smart cards and storing cardholder data on 
smart cards. The Advisory Action provides that Du is in the field of smart cards, 
however, smart cards are only used as a means for storing a user's personal computing 
configuration. They are using the smart card as an end product, downstream from the 
actual manufacturing of the smart card. The present invention and Tushie deal with 
manufacturing the smart card, an activity that may be described as being upstream in the 
smart card lifecycle. As such, there is no apparent reason to combine Du with Tushie. 

For these reasons, it is respectfully submitted that claims 1 and 1 1 are not 
unpatentable over Tushie in view of Du. 

E. "Personalization data file" Is Not Disclosed 

The claims also recite the step of generating a "personalization data file" used for 
personalizing a batch of smart cards by providing smart card features on each smart card 
in the batch. Neither Du or Tushie, alone or in combination, discloses or suggests 
generating the claimed personalization data file. The term "personalization data file" 
must be interpreted in light of the claims and specification. The claim language requires 
that it be generated from a modified default member profile and that it be suitable for 
personalizing a batch of smart cards using output data values, the output data values 
representing smart card features. The final action cites a section of Du that describes 
updating indices related to the user's personal computing environment. This has no 
bearing on the claimed personalization data file. No such file is mentioned or implied in 
Du. The final action also cites a section of Tushie describing a system for personalizing a 
smart card with cardholder data. However, as described above, Tushie discloses a system 
in which smart cards are personalized with individual cardholder data, such as account 
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number, user name, address, and so on. This is in contrast to the claimed feature data 
representing a business requirement of the smart card issuer. 

F. Final Step of Claim 11 Is Not Disclosed 

Furthermore, claim 1 1 recites the step of actually personalizing the batch of smart 
cards using the personalization data file. As noted, this personalization data file includes 
output data values that represent the smart card features desired by the smart card issuer. 
The final action cites the personalization system in Tushie. However, as noted earlier, 
Tushie uses the term "personalization" in a different context from that of the claimed 
invention. The personalization data in Tushie does not relate at all to smart card features 
as decided by a smart card issuer, but rather is directed to basic cardholder data. Basic 
cardholder data is not "a parameter representing an issuer business requirement dictating 
smart card usage" as required in claim 11. 

XIII. CONCLUSION 

In view of the foregoing, Appellants respectfully request that the Board reverse 
the Examiner's rejection of all pending claims. In addition, Appellants believe all claims 
now pending in this application are in condition for allowance. The issuance of a formal 
Notice of Allowance at an early date is respectfully requested. 

Respectfully Submitted, 
BEYER LAW GROUP LLP 
/Rupak Nag/ 
Rupak Nag 

Registration No. 37,493 
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IX. CLAIMS APPENDIX 



CLAIMS ON APPEAL 



1. (rejected) A method for automating the personalization of a batch of smart cards that 
originates with a smart card issuer, said method comprising: 

executing a personalization assistant software tool, said software tool including a 
default member profile having default values for smart card features, a smart card feature 
being a parameter representing a business requirement of said smart card issuer dictating 
smart card usage; 

providing a user with a plurality of queries regarding said smart card features, said 
queries originating from said software tool; 

receiving from the user, responses to the plurality of queries, said responses being 
received by said software tool and reflecting smart card features desired by said smart 
card issuer; 

matching each of said responses with an output data value, said matching being 
performed by said software tool, each of said output data values representing one of said 
smart card features and being suitable for personalizing a smart card; 

modifying said default member profile to include said matched output data values, 
said output data values replacing corresponding said default values for smart card 
features; and 

generating a personalization data file from said modified default member profile, 
wherein said personalization data file is suitable for personalizing said batch of smart 
cards and provides said smart card features on each smart card in said batch of smart 
cards by way of said output data values. 

2. (rejected) The method, as recited in claim 1, further comprising: 
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using individual cardholder input files and the personalization data file to 
personalize said batch of smart cards to yield a plurality of personalized smart cards. 

3. (rejected) The method, as recited in claim 1, wherein said matching includes: 

providing a look up table with entries for various combinations of responses to the 
plurality of queries; 

finding a matching entry in the look up table that matches the responses to the 
plurality of queries; 

locating one of said output data values associated with the matching entry; and 
outputting the one of said output data values associated with the matching entry. 

4. (rejected) The method, as recited in claim 1, wherein the plurality of queries, 
comprise: 

at least one query regarding smart card account usage control; 

at least one query regarding smart card account risk management; and 

at least one query regarding offline limits and thresholds. 

5. (rejected) The method, as recited in claim 4, wherein responses to the plurality of 
queries are used to provide best practices recommendations. 

6. (rejected) The method, as recited in claim 1, further comprising: 

providing regional profiles and subregional profiles, wherein a subregion is within 
a region, wherein the regional and subregional profiles have mandatory and 
recommended settings, wherein some of the subregional profiles are more stringent than 
regional profiles in which the subregions belong. 
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7.-11 (Cancelled) 



1 1 . (rejected) A computer implemented method for automating the personalization of a 
batch of smart cards that originates with a smart card issuer, comprising: 

running on a host computer a personalization assistant software application, said 
software application including a default member profile having default values for smart 
card features, a smart card feature being a parameter representing an issuer business 
requirement dictating smart card usage; 

providing to at least one user over a network a plurality of queries regarding said 
smart card features, said queries originating from said software application; 

receiving from the at least one user over the network responses to the plurality of 
queries, said responses being received by said software application and reflecting smart 
card features desired by said smart card issuer; 

matching each of a plurality of combinations of said responses with an output data 
value, said matching being performed by said software application; 

modifying said default member profile to include said matched output data values, 
said output data values replacing corresponding said default values for smart card 
features; 

generating a personalization data file from said modified default member profile, 
wherein said personalization data file is suitable for personalizing said batch of smart 
cards and provides said smart card features on each smart card in said batch of smart 
cards by way of said output data values; and 

personalizing said batch of smart cards utilizing said personalization data file, said 
personalization data file providing said smart card features on each smart card in said 
batch of smart cards by way of said output data values. 

12. (rejected) The computer implemented method, as recited in claim 11, further 
comprising: 
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sending the personalization data file to a preparation processing device; and 
using the personalization data file and cardholder input files to personalize smart 

cards. 

13. (rejected) The computer implemented method, as recited in claim 11, wherein said 
matching includes: 

providing a look up table with entries for various combinations of responses to the 
plurality of queries; 

finding a matching entry in the look up table that matches the responses to the 
plurality of queries; 

locating one of said output data values associated with the matching entry; and 
outputting the one of said output data values associated with the matching entry. 

14. (rejected) The computer implemented method, as recited in claim 11, wherein the 
plurality of queries, comprise: 

at least one query regarding smart card account usage control; 

at least one query regarding smart card account risk management; and 

at least one query regarding offline limits and thresholds. 

15. (rejected) The computer implemented method, as recited in claim 14, wherein 
responses to the plurality of queries are used to provide best practices recommendations. 

16. (rejected) The computer implemented method, as recited in claim 11, further 
comprising providing regional profiles and subregional profiles, wherein a subregion is 
within a region, wherein the regional and subregional profiles have mandatory and 
recommended settings, wherein some of the subregional profiles are more stringent than 
regional profiles in which the subregions belong. 
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17.- 35. (Cancelled) 
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X. EVIDENCE APPENDIX 



No evidence has been submitted pursuant to §§ 1.130, 1.131, or 1.132 of 37 CFR, 
nor has any other evidence been entered by the examiner. 
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XL RELATED PROCEEDINGS APPENDIX 

There have been no decisions rendered by a court or the Board in any proceeding 
identified pursuant to paragraph (c)(l)(ii) of 37 CFR 41 .37(c)(1). 
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